Skip to content

Fix ValueOption optional args with ?param caller syntax#19742

Open
T-Gro wants to merge 1 commit into
mainfrom
fix/valueoptions-optionals
Open

Fix ValueOption optional args with ?param caller syntax#19742
T-Gro wants to merge 1 commit into
mainfrom
fix/valueoptions-optionals

Conversation

@T-Gro
Copy link
Copy Markdown
Member

@T-Gro T-Gro commented May 15, 2026

Fix caller-side ?name = expr syntax for ValueOption optional parameters when SupportValueOptionsAsOptionalParameters is enabled.

Fixes #19711

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 15, 2026

❗ Release notes required


✅ Found changes and release notes in following paths:

Change path Release notes path Description
src/Compiler docs/release-notes/.FSharp.Compiler.Service/11.0.100.md

@T-Gro T-Gro requested a review from abonie May 15, 2026 12:26
@T-Gro T-Gro added AI-Auto-Resolve-Conflicts Opt-in: LabelOps merges main into this PR and resolves conflicts every 3h AI-Auto-Resolve-CI Opt-in: LabelOps triages CI failures on this PR every 3h labels May 15, 2026
When the SupportValueOptionsAsOptionalParameters language feature is
enabled, do not force option<_> on caller-side ?name = expr arguments
during overload inference. Leave the type as a fresh inference variable
and let AdjustCalledArgTypeForOptionals (CalleeSide) reconcile against
option<_> or voption<_>.

Pre-LangVersion-10 behaviour is preserved.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@T-Gro T-Gro force-pushed the fix/valueoptions-optionals branch from 01ce17d to a53024c Compare May 15, 2026 12:26
@github-actions github-actions Bot added the AI-Tooling-Check-Bypassed Tooling check: non-fork PR, not diff-analyzed label May 15, 2026
@github-actions github-actions Bot mentioned this pull request May 15, 2026
Copy link
Copy Markdown
Member Author

@T-Gro T-Gro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clean, well-scoped fix. The root cause was that TcMethodApplication_SplitSynArguments eagerly constrained the caller argument type to option<_> when the ?param = expr syntax was used, preventing ValueOption from ever unifying correctly.

The fix correctly gates on SupportValueOptionsAsOptionalParameters to leave the type as a fresh inference variable when the feature is enabled, letting later unification in AdjustCalledArgTypeForOptionals (CalleeSide branch) match the actual declared parameter type — whether option<_> or voption<_>.

Key points verified:

  • Correctness: The CalleeSide branch at line 382 passes through calledArgTy unchanged (which already handles both option/voption), so the deferred unification naturally resolves to the right wrapping type.
  • Backwards compat: LangVersion < 10 preserves old behavior (early option<_> constraint).
  • Test coverage: Methods, constructors, both option variants, and langversion gating are all exercised.
  • No inference regressions: Since None/Some and ValueNone/ValueSome are unambiguous on their own, removing the early constraint doesn't create inference ambiguity for practical cases.

LGTM ✅

@T-Gro T-Gro added the AI-reviewed PR reviewed by AI review council label May 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI-Auto-Resolve-CI Opt-in: LabelOps triages CI failures on this PR every 3h AI-Auto-Resolve-Conflicts Opt-in: LabelOps merges main into this PR and resolves conflicts every 3h AI-reviewed PR reviewed by AI review council AI-Tooling-Check-Bypassed Tooling check: non-fork PR, not diff-analyzed

Projects

Status: New

Development

Successfully merging this pull request may close these issues.

ValueOption optional parameters cannot be passed as ValueOptions

1 participant